1747343 - Want a special file handler for all non-configured MIME types, so that "always ask" can be set to the default behavior

Status: VERIFIED FIXED

(Firefox :: Settings UI, enhancement, P1)

Description

[Shane Hughes [:aminomancer]]

When browser.download.improvements_to_download_panel = true the default open/save behavior is no longer configurable. User can only set specific handlers via the downloads panel context menu or by editing handlers.json in a text editor. I and other users download a variety of files so being able to set the default behavior will lift a burden of needing to set the behavior for every individual mime type, and help soften the blow of not being able to set the behavior for a given type of file until after an instance of it has already been downloaded.

The default action for an unknown/unconfigured content type should still be to skip the unknown content type dialog and save the file, so this isn't inconsistent with the planned changes. But there should be a way to override the default flow to "always ask" so you get the UCT dialog for unknown/unconfigured files. My personal desire would be to set it to "Always ask," but this would also allow users to set it to "Save file," "Use system viewer," or "Use other..." just like you can do with a normal file handler.

This could be in the form of some kind of preference exposed in about:preferences, but I think it'd be better to add a virtual file handler in handlers.json so it'll always display in the about:preferences handlers richlistbox. The latter could go at the very end of the list, labeled "All other types," or it could go at the top of the list and be labeled "Unknown" or "Unconfigured" or something.

How (or if) that should appear in handlers.json I don't know. I know you can add text/plain or application/octet-stream and maybe you can add application/unknown by hand. But those aren't gonna actually handle "everything else" so it's not quite the same thing. This proposal entails changing handling not just for application/unknown or text/plain, but for ALL content types that aren't explicitly handled in the user configuration. In other words, this is like the wildcard handler.

Right now, all unhandled content types are handled in a particular way, (saving the file) it's just not controllable by the user. So the proposal isn't changing much in terms of behavior, it's just moving that behavior into a more configurable space. But that current behavior isn't implemented in JSON at all. I guess I'm proposing that it be implemented in JSON with a kind of fake MIME type, like this:

"unconfigured/unknown": { "action": 0, "ask": true }

Or, if that causes problems, at least it could be implemented in such a way that it can be visually spoofed in the handlers view richlistbox in about:preferences. I do think the most intuitive interface for this is in that richlistbox, since it makes it very clear that it controls the behavior of "all the other content types." So finding a way to display it in that list would make it more accessible, whether it's actually a normal handler or not.

Thanks 🙏

Comment 1

[:Gijs (he/him)]

the default open/save behavior is no longer configurable

"no longer" implies that it could be done before, and I don't think that's true? Can you clarify what you mean?

(In reply to aminomancer from comment #0)

would also allow users to set it to "Save file," "Use system viewer," or "Use other..."

"use other" makes no sense because you cannot really have a meaningful app that handles literally "any file you open". "Use system viewer" is a potential security risk (e.g. you click a link that points to a python file and now it executes in python) so I don't think we want to do that, either.

Whether this is necessary is a question for product, I think.

I think rather than putting this in the JSON format, which would require changes to the format and how it's used, it'd be easier to use prefs... but that's an implementation detail.

Romain/Ray, can you offer thoughts on what you want to do here?

Comment 2

[Romain Testard [:RT]]

Can you please say a little more about use cases for downloading/opening so many different mime types?
I'm skeptical about the representativity of ". I and other users download a variety of files so being able to set the default behavior will lift a burden of needing to set the behavior for every individual mime type, and help soften the blow of not being able to set the behavior for a given type of file until after an instance of it has already been downloaded."
99% of Firefox users who download, will download less than 16 different mime types in a 6 months period (77% will download less than 6) and obviously these users would likely already have downloaded such mime types before that.
Adding preferences brings complexity to the preferences UI and we should ensure that the use case is relevant enough to justify it.

Comment 3

[Shane Hughes [:aminomancer]]

Great, thanks for the replies! I will try to respond in order.

(In reply to :Gijs (he/him) from comment #1)

the default open/save behavior is no longer configurable

"no longer" implies that it could be done before, and I don't think that's true? Can you clarify what you mean?

It couldn't be configured as a "pseudo-handler" the way I'm proposing, but with the download flow improvements disabled, when an unknown file is encountered the UCT dialog appears unless the user has useDownloadDir enabled. So you didn't have fine-grained control over it since toggling that pref would change the behavior for real handlers as well. But the big difference is that with useDownloadDir disabled, it'd ask you what to do with unconfigured files rather than immediately saving them. I'm not suggesting that we make an option that simply undoes the improvements, rather that we make a further improvement that allows configuring the default behavior for all unconfigured files without changing useDownloadDir.

would also allow users to set it to "Save file," "Use system viewer," or "Use other..."

"use other" makes no sense because you cannot really have a meaningful app that handles literally "any file you open". "Use system viewer" is a potential security risk (e.g. you click a link that points to a python file and now it executes in python) so I don't think we want to do that, either.

Well I have VS Code set as the unknown file handler on my Windows 10 workstation. Works fine for me. But yeah I can see how these would constitute a security risk. That's really not the crux of my proposal, I have no intention of setting unconfigured files to "Open" at all, simply to "Always ask." I think the basic need here is to be able to choose whether files of unknown/unconfigured mime type 1) simply save to the downloadDir, or 2) prompt the user with the UCT dialog.

So, the only choices that need to appear in the menulist are "Always ask" and "Save File" (for some reason those strings are cased inconsistently). The rest was just brainstorming, but if someone finds that it's safe and practical to include more, then that's great too.

I think rather than putting this in the JSON format, which would require changes to the format and how it's used, it'd be easier to use prefs... but that's an implementation detail.

Yeah I thought that there would be issues with putting it in JSON. Even just making a radio button under the richlistbox would be fine, but I just think it'd be really cool if we can find a way to make a fake richlistitem for "Unknown Files" (or whatever the label should be, I'm sure there's a better name for this but "Unconfigured Files" is kinda jargony) because that would reduce the amount of explaining the label needs to do. By appearing in the list of handlers it's more obvious that it's functionally a kind of abstract file handler. So it wouldn't need a description like What should Nightly do with unknown or unconfigured files? — Always ask/Save File. That's more complicated than making a radio button, but I'm pretty sure that aspect of this is something I can contribute myself.

(In reply to Romain Testard [:RT] from comment #2)

Can you please say a little more about use cases for downloading/opening so many different mime types?

Sure. I work in educational media design, so I am using Firefox like 8+ hours a day. I could be developing LMS software today and editing video tomorrow. I'm downloading many different file formats in varying ways from varying sources, some may not always have a useful mime type or even a file extension. Every publisher has their own proprietary crap. Firefox's dialog for protocol handlers is fabulous and works great for me, as a comparison. I also have to download stuff through unconventional means pretty routinely, like downloading from a blob or data URI with an extension is pretty common. LMS services use a variety of mime types depending on how the file is downloaded (the most ubiquitous one is a CSV file with no extension), and probably the craziest example is downloading footage and metadata from Sony video cameras like the F55 for review without needing to spend time zipping them. And of course there are all manner of types for source code that I want to open in half a dozen different programs. I'm sure other people have totally different considerations. I've accumulated a long list of file handlers in Firefox over the years, but that won't help when I run into a new file or download a file in such a way that it's not matched to one of the existing handlers.

As a general rule, I don't want to always treat a file of a given type the same way. Like, let's say I only downloaded PDFs. Sometimes a PDF I download is a form I need to fill out, so I want to open it in Acrobat. Other times, it's just a flyer or something I want to look at in Firefox. Other times, it's a "printed" confirmation form that I don't want to open at all, merely download for recordkeeping. That's not a problem if I only download PDFs, since I can configure the PDF handler's action. But what if the pattern I just described applied to dozens or hundreds of file types?

It's not just about my own installation though. I have to manage teams of freelancers who will need to download the same kinds of files, across disciplines. Newer users aren't going to have that long list of handlers in the first place. It's right that the default behavior is to save the file without prompting the user to choose an action. But if I had started using Firefox today (with the improvements enabled) it'd be a nightmare. I would have to download a file of unknown type, let Firefox save it without a prompt, then open the downloads panel, right click the item, click the menuitem that'll add a handler to the JSON file, then go into about:preferences and configure it. And again for every type. Fortunately I already have handlers there for most of the files I routinely come across, but there are still odd ducks.

99% of Firefox users who download, will download less than 16 different mime types in a 6 months period (77% will download less than 6) and obviously these users would likely already have downloaded such mime types before that.

I don't know about the methodology so I can't argue fluently about this particular point. But it doesn't seem like that reflects the number of times a user encounters a file without a recognized mime type. That's why I used the phrase "unknown/unconfigured" in my original post. And (this seems like a lesser issue but) it also doesn't indicate how many of those 16 types were new, viz., how many would require the user to manually add a new content type via the context menu and manually set its action in AboutPreferences (once the improvements release).

But I think this may be a bit of a red herring. Even if 99% of users only downloaded less than 16 different mime types in their entire lifetime, I don't see a compelling reason for Firefox not to allow configuration of the default behavior underlying all of this. Handlers are behavior layered on top of something else. What happens when you remove all the handlers? It isn't implemented like this semantically, but that behavior amounts to something you could call the "default handler." And currently the user can't decide what that behavior does, making it uniquely opaque.

So I'd argue the enhancement is justified even if for no other reason than the sake of consistency. But for some users it's also going to reduce the amount of time spent setting up individual handlers. Check out the list, my handlers.mimeTypes is 160 properties long and growing, and I haven't even seen 1% of these. If I had to start over, it already would be so annoying to add 160 handlers via the current method (download file > context menu) that I would wind up typing them into handlers.json by hand instead. But in principle I could need to add way more than 160, given how many there actually are.

Of course most Firefox users don't see enough variety in downloads to care one way or the other. I said in the first post that I don't think the default action should change, since most users will be content to simply save unknown types. But Firefox has thousands of prefs, and most of them are not necessary for the majority of users. This is definitely more of a "power user" feature, but if it's practical to implement and it's not causing any other problems, then it's worth adding.

(I would err on the side of caution if someone can identify a security issue, but it seems like, if anything, letting the user choose "Always ask" makes them marginally safer) Another way of phrasing this is that if 1% of users download way more mime types than the average user does, and they don't just want to save all of them to disk without a prompt, this download flow update is gonna negatively impact their experience, but we could prevent that with (as far as I can tell) a pretty small patch.

Adding preferences brings complexity to the preferences UI and we should ensure that the use case is relevant enough to justify it.

That's definitely a strong argument, but like I mentioned before, this is more of a "power user" feature. The interest in keeping AboutPreferences minimal shouldn't be taken as an argument against this enhancement, because this feature doesn't need to be exposed in AboutPreferences at all. Like I mentioned before, we have thousands of preferences and only a tiny fraction are represented in the UI. I suspect that the set of users who download large varieties of files and care enough to navigate to about:preferences to mess with the handlers list overlaps significantly with users who change prefs via about:config or user.js.

That said, I still think it's worth adding it to AboutPreferences, because by adding it to the richlistbox in the form of a normal handler, it's hardly increasing the complexity of the interface. It's just increasing the quantity of richlistitems by 1, so in terms of UX its impact is no different from any other handler. And if we don't make this enhancement, and the user wants to achieve something similar, they're gonna need to add handlers to that list anyway.

Comment 4

[Shane Hughes [:aminomancer]]

I also meant to say if we're worried about the user unintentionally clicking open on unknown binaries, application/octet-stream could be like, an exception to the 'default handler' such that it skips right to saving. Just like when you would download an MSI file and only get a dialog with "Save File" and "Cancel" except no need for the dialog in the first place. And if I understand correctly, even before all this, the file was actually already downloading or finished downloading before the dialog appeared, and "Cancel" just deleted it from the temp folder?

Comment 5

[Andrei Purice]

Setting this enhancement to NEW in order for it to gain visibility.

Comment 6

[Shane Hughes [:aminomancer]]

Attachment: A mockup of how this would look for a new user

Here's a quick mockup of how I'm envisioning this would look for a new user. With the default action set to "Save File" the normal flow won't be changed by this enhancement.

Comment 7

[Shane Hughes [:aminomancer]]

Attachment: An alternative approach

And if adding a fake richlistitem causes trouble we can do something like this instead

Comment 8

[stine]

I'm an network/system/application administrator. When I click on a download link, I want to be able to select, EVERY TIME I click on a file, to be presented with the option to save, to open, or to cancel the download. I don't want the file type to have any bearing on the action taken by Firefox because I'm going to need to make that decision every time I download a file. If I'm downloading an audio file, i might want to open it in an audio player, or i might want to save it to disk. As far as I can tell, the developers have decided that I'm only every going to perform a single action when downloading a file type. Can someone explain this to me?

Comment 9

[Shane Hughes [:aminomancer]]

I'm willing to work on this if I can get some assurance that the enhancement is desired. I posted some mockups of 2 different UI approaches a few months ago, but a 3rd approach would be simply adding a pref but not exposing it in the UI anywhere. The pref implementation and the UI display can be 2 consecutive patches. I think this is a pretty simple change. If Gijs is free to review it I'm sure we can finish it in a couple days.

Comment 10

[aoia7rz7l]

Sorry for chiming in, but if this can't/won't be handled via handlers.json alone, it would be nice for this to be put behind a pref, similar to how the Always ask you where to save files in the UI controls browser.download.useDownloadDir. This would help deployment via, for example, user.js.

Comment 11

[Shane Hughes [:aminomancer]]

(In reply to aoia7rz7l from comment #10)

Sorry for chiming in, but if this can't/won't be handled via handlers.json alone, it would be nice for this to be put behind a pref, similar to how the Always ask you where to save files in the UI controls browser.download.useDownloadDir. This would help deployment via, for example, user.js.

Good point. I think having an actual handler is probably overkill, seeing as probably very few people try to edit handlers by editing handlers.json. If we can get a richlistitem to appear in the UI that looks like a handler, but really just corresponds to a pref, that sounds good enough to me

Comment 12

[Romain Testard [:RT]]

Thanks Shane and apologies for the delay in my answer. I feel like your proposal on Comment 6 is a good approach that brings a solution to the use case while not adding new preferences which would clutter the UI. We can also create a SUMO age that explains how to handle this particular use case with this change.
I'll check if UX is supportive of the proposal and if so I agree we should move forward with Comment 6

Comment 13

[Shane Hughes [:aminomancer]]

Sounds great, thanks for the update.

Comment 15

[Romain Testard [:RT]]

(In reply to Shane Hughes [:aminomancer] from comment #13)

Sounds great, thanks for the update.

I reviewed with Aaron from UX who is willing that we follow the proposal on Comment 7.
Meridel, can you please help assign someone who could help review the strings proposed on Comment 7?
Shane, I realize it took a little while to get there but we'd still very much welcome your contribution for this patch so thanks for letting us know if this is still something you'd be available to help with (Comment 7)!

Comment 16

[Shane Hughes [:aminomancer]]

Sure, the way in Comment 7 should be much easier so that's a relief haha. Unless anyone else wants to take it, I will

Comment 17

[:Gijs (he/him)]

Using a pref for the implementation (rather than handlers.json) sounds great to me.

Comment 18

[Shane Hughes [:aminomancer]]

I noticed there are some older tests that use the alwaysAskBeforeHandling flag for testing purposes, with the expectation that the flag will be true by default (as it was before the downloads panel improvements). Here's an example. Basically it's setting the flag to false so that it can check later that it was stored correctly. But I don't think it would be able to detect a regression anymore because the flag is now false by default, at least for the conditions under which this test should be running. I think I saw some other instances of the same kind of thing but I wasn't quite as certain what they were trying to do and really just skimmed over them. I haven't done an exhaustive search, just noticed it in the process of working on this and wanted to make a note of it before I forget.

Comment 19

[Shane Hughes [:aminomancer]]

Attachment: Bug 1747343 - Add pref to set default action for new mimetypes. r=Gijs

When downloading a file, we check for existing mime types and construct
a new one if it's unrecognized. Mime types have a flag,
alwaysAskBeforeHandling, that determines whether the unknown content
type dialog should be opened before handling the file. Before bug 1733492,
the default value for that flag was simply true. Since the new
downloads flow is intended to avoid unnecessary steps, the default value
was changed to the inverted value of the new downloads panel
improvements pref. This patch adds a new pref that the mime info
constructor will read in configuring the flag's value. If the
improvements pref is not enabled, then the flag will be true, so the UCT
dialog will open. If the improvements pref is enabled, then it'll use
the value of the new pref. Also add a an interface for the pref to the
about:preferences UI. This interface is disabled when the improvements
pref is disabled, because the pref doesn't really do anything in that
case. But that shouldn't matter much since that pref is enabled by
default now. I'm updating some tangentially related test files since
they happen to be touched slightly by this change. Strictly speaking
they would still work, but if the pref value was somehow changed from
the default they would fail.

Comment 20

[Kelimutu [:kiki]]

(In reply to Shane Hughes [:aminomancer] from comment #19)

When downloading a file, we check for existing mime types and construct a new one if it's unrecognized.

Does this mean that a new mime types will be automatically added to the Application list based on the setting that we set on comment #7 ?

If that's the case, I think it'll also solve the confusion around adding a new content type. This might be subtle, but can be frustrating at times. I know we can choose the option to "always open similar files", but it's not in any way a direct way to add a new mime type.

If we can also automate the action of adding the mime type with this proposal, it'll lift a huge burden for these type of folks:

• https://twitter.com/AbdullahNimer96/status/1506886546477232132
• https://twitter.com/jlpsays/status/1509599171640238093
• https://twitter.com/IanusJWolf/status/1504164263123857411
• https://support.mozilla.org/en-US/questions/1371550
• https://support.mozilla.org/en-US/questions/1372331
• https://support.mozilla.org/en-US/questions/1372214
• https://support.mozilla.org/en-US/questions/1372228
• https://support.mozilla.org/en-US/questions/1371070

Comment 21

[Kelimutu [:kiki]]

Relevant SUMO discussion about the topic: https://support.mozilla.org/en-US/forums/contributors/715624?page=3#post-83253

Comment 22

[:Gijs (he/him)]

(In reply to Kelimutu [:kiki] from comment #20)

(In reply to Shane Hughes [:aminomancer] from comment #19)

When downloading a file, we check for existing mime types and construct a new one if it's unrecognized.

Does this mean that a new mime types will be automatically added to the Application list based on the setting that we set on comment #7 ?

No.

If that's the case, I think it'll also solve the confusion around adding a new content type.

I think it obviates the need for this; if users want to change files to "always ask", they set the default to always ask, then there's also no need to add additional mimetypes. On top of that, when the default is to show the old "what do you want to do with this file" dialog, the dialog itself provides options to always save/open (and the dialog is a bit too happy to save mimetype info into the application list anyway).

Comment 23

[Shane Hughes [:aminomancer]]

(In reply to Kelimutu [:kiki] from comment #20)

(In reply to Shane Hughes [:aminomancer] from comment #19)

When downloading a file, we check for existing mime types and construct a new one if it's unrecognized.

Does this mean that a new mime types will be automatically added to the Application list based on the setting that we set on comment #7 ?

If that's the case, I think it'll also solve the confusion around adding a new content type. This might be subtle, but can be frustrating at times. I know we can choose the option to "always open similar files", but it's not in any way a direct way to add a new mime type.

Thanks for sharing all the links, that's really helpful. I misspoke in my patch description. My bad. I should have said we check for an existing mimeInfo in the handler service, and if the type is not recognized we construct a new one. By construct I just mean we use the constructor that I modified. A new mimeInfo being constructed doesn't necessarily mean that a handler will be added via handlers.json.

A handler will only be added if the user uses the "Always open similar files" menuitem on a download element, or uses the "Do this automatically for files like this from now on" checkbox in the UCT dialog (well maybe there are other cases I haven't encountered but these are at least the universal ones). So there is a way to add a handler, whether you enable this new pref or not. But certainly handlers don't need to be added if their action is the same as the global default action (which is set by this new pref).

So think about it like this, if I enable this new pref (What should Firefox do with other files?: Always ask) and I download a file of unrecognized type, then the UCT dialog is going to open. That dialog provides 1 of 2 layouts which contain all the possible actions. And it has a checkbox that lets me save my choice. So from there I can create a handler for future downloads.

The one thing I can't do is create a handler with action=alwaysAsk. Because "Do this automatically" means do the action I choose here automatically. And the action alwaysAsk would just result in opening another UCT dialog. So if we had that option in the UCT dialog of course it would just create a dialog loop. But it's fine not to put that option in the UCT dialog, because there's no need to create a handler for a mime type if the handler's action is just going to be the same as the default action. It won't result in any behavioral difference. The handler only matters insofar as it deviates from the global default. And that was the main rationale for this enhancement — before this, the global default was always saveToDisk.

However, I do think we could make an improvement for users who want saveToDisk to be the global default action, but want to be able to set some mime types to alwaysAsk. In that case, users have to...

1. Download a file of the type in question
2. Let the file save
3. Open downloads panel
4. Right-click the download element
5. Select "Always open similar files"
6. Let Firefox open the file (because this action doesn't only make a handler, it also opens the file — maybe that's not so good after all?)
7. Close whatever application it opened in
8. Go to about:preferences, find the Applications richlist
9. Find the new mime type
10. Set it to "Always ask"

I agree with jscher2000 on this point:

The only way to select "Always Ask" is through the Settings page. It would be preferable if this could be done in a single step through the menu. Perhaps using a fly-out menu like the tri-state menu for the Bookmarks Toolbar.

I think that might be useful to have for the downloads panel. If the "Always open similar files" menuitem was replaced by a menu that contained menuitems for all the valid actions (this would have the same items as the menulist for the mime type in the richlist in about:preferences), then the user could immediately choose "Always ask" from this list without having to open the file (and of course, without having to make "Always ask" the global default).

Comment 24

[jscher2000]

Hi Shane, since I'm mentioned by name: I wouldn't want the extra UI complexity I suggested to divert from the core issue here of handling unknown content types. We could open a separate bug for the downloads context menu enhancement.

It's not to up to me, of course, but I would start with a preference (for example, browser.download.saveUnknownTypes with a default of true) (I have no idea how these names are selected), and working that into the download flow.

And then the UI implementation in Comment 7 hopefully can be ready by Firefox 100 but, if not, at least we'll have the preference to tide us over if everything tests out.

Comment 25

[Kelimutu [:kiki]]

(In reply to Shane Hughes [:aminomancer] from comment #23)

So think about it like this, if I enable this new pref (What should Firefox do with other files?: Always ask) and I download a file of unrecognized type, then the UCT dialog is going to open. That dialog provides 1 of 2 layouts which contain all the possible actions. And it has a checkbox that lets me save my choice. So from there I can create a handler for future downloads.

Thanks for your explanation. I get your point now. I was just too excited over the misinterpretation of your line above. But yeah, I guess it makes sense. People who choose "always ask", might do it because they want to be careful in general. Assuming that, they may less care about setting the preferences per each mime type. Please excuse me since I don't want to overcomplicate the solution discussed in this bug, which in my opinion, already solve a huge problem.

But yeah, I still agree that there's still an opportunity to improve the experience of adding a new mime type, which is worth another separate discussion.

(In reply to jscher2000 from comment #24)

Hi Shane, since I'm mentioned by name: I wouldn't want the extra UI complexity I suggested to divert from the core issue here of handling unknown content types. We could open a separate bug for the downloads context menu enhancement.

Would you like to file a new bug for that, Jscher?

Comment 26

[Shane Hughes [:aminomancer]]

My tendency was previously to add as many handlers as I can, so my handlers.json file really swelled up. It can be hard to find the things I actually care about so maybe it would be nice to have an easy way to delete obsolete handlers, without needing to edit the handlers.json file. In retrospect, since I'm mostly setting them to "Always ask" now, I really don't need any of them except for the protocol handlers. Especially since some of these types have obscenely long names like Microsoft Word Document (application/vnd.openxmlformats-officedocument.wordprocessingml.document) haha. Gee thanks for that, Microsoft.

If anyone makes a bug for the context menu thing, feel free to needinfo me or attach it to this one under "see also"

Comment 27

[Betsy Mikel [:betsymi]]

Huge thanks Gijs for helping bring me up to speed and understand the ask here. Here are strings for the bottom of the dialog.

What should Nightly/Firefox do with other files?

• Save files
• Ask whether to open or save files

Comment 28

[:Gijs (he/him)]

(In reply to Betsy Mikel [:betsymi] from comment #27)

Huge thanks Gijs for helping bring me up to speed and understand the ask here. Here are strings for the bottom of the dialog.

What should Nightly/Firefox do with other files?

• Save files
• Ask whether to open or save files

Shane, would you mind updating the patch for these new strings? Thank you!

Comment 29

[Shane Hughes [:aminomancer]]

(In reply to :Gijs (he/him) from comment #28)

Shane, would you mind updating the patch for these new strings? Thank you!

Done!

Comment 30

[:Gijs (he/him)]

Thanks Shane! The patch is queued for autoland now.

I'm going updating the other release flags to try to be clear about this immediately: because the patch involves new UI, and that UI is localized, unfortunately it won't be possible to uplift it to beta, and so it won't go out any sooner than 101 (due for release at the end of next month).

Comment 31

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/543a78ca4fa9
Add pref to set default action for new mimetypes. r=Gijs,fluent-reviewers,preferences-reviewers

Comment 32

[Atila Butkovits]

Backed out for causing mochitest failures at browser_bug676619.js.

Backout link: https://hg.mozilla.org/integration/autoland/rev/a263ac3f49c03315f03691e4430953f9d24421f9

Push with failures: https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=543a78ca4fa91f4ae862fd5e698a743c73d1b2f9

Failure log:
-https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=543a78ca4fa91f4ae862fd5e698a743c73d1b2f9

-https://treeherder.mozilla.org/jobs?repo=autoland&resultStatus=testfailed%2Cbusted%2Cexception%2Cretry%2Cusercancel&revision=543a78ca4fa91f4ae862fd5e698a743c73d1b2f9&selectedTaskRun=fAFgOK_DRYu8GLv9y6D20Q.0

Comment 33

[Shane Hughes [:aminomancer]]

Thanks I'm working on the tests

Comment 34

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/a941cd19ec11
Add pref to set default action for new mimetypes. r=Gijs,fluent-reviewers,preferences-reviewers

Comment 35

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/a941cd19ec11

Comment 36

[Shane Hughes [:aminomancer]]

I'm not super familiar with SUMO, but it seems like the route we ended up taking is simple enough that it probably doesn't need a new page. I'm guessing it would fit well on this page, under the Changing download actions section. The first sentence of the "What should Firefox do with this file?" prompt section also touches on this topic, but I can't really think of a non-confusing way to explain this new pathway into the UCT dialog. Version 101 doesn't show up in the dropdown yet so maybe this has to be added later?

edit: Looks like AliceWyman has already gotten started with that. Thanks everyone~

Comment 37

[Alice Wyman]

(In reply to Shane Hughes [:aminomancer] from comment #36)

I'm not super familiar with SUMO, but it seems like the route we ended up taking is simple enough that it probably doesn't need a new page. I'm guessing it would fit well on this page, under the Changing download actions section. The first sentence of the "What should Firefox do with this file?" prompt section also touches on this topic, but I can't really think of a non-confusing way to explain this new pathway into the UCT dialog. Version 101 doesn't show up in the dropdown yet so maybe this has to be added later?

edit: Looks like AliceWyman has already gotten started with that. Thanks everyone~

I set up a needs change entry and will work on this when Firefox 101 goes into beta. See this discussion thread I started:
https://support.mozilla.org/en-US/kb/change-firefox-behavior-when-open-file/discuss/10612 [Fx101] New "Always ask" setting for non-configured MIME types (Bug 1747343)

Comment 38

[Ardelean Oana, Desktop QA [:oardelean]]

I confirm this enhancement is implemented on Firefox 101.0b8(20220517185920) and Nightly 102.0a1(20220517092745) on macOS 11, Windows 10 64-bits and Ubuntu 20.04.

Comment 39

[Dalacor]

I have used the user.js setting - "browser.download.always_ask_before_handling_new_types" and can confirm that this works in ESR version. I am not able to find the enterprise group policy setting or more specifically the registry key for this setting. Is there one? Thanks

Comment 40

[Shane Hughes [:aminomancer]]

(In reply to Dalacor from comment #39)

I have used the user.js setting - "browser.download.always_ask_before_handling_new_types" and can confirm that this works in ESR version. I am not able to find the enterprise group policy setting or more specifically the registry key for this setting. Is there one? Thanks

There isn't a policy or registry key for this preference. You could file a bug to request one

Comment 41

[Dalacor]

(In reply to Shane Hughes [:aminomancer] from comment #40)

There isn't a policy or registry key for this preference. You could file a bug to request one

Thank you. I will make a request in a new topic now.